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Current approaches for the discovery, specification, and provision of services ignore the relationship 
between the service contract and the conditions in which the service can guarantee its contract. More- 
over, they do not use formal methods for specifying services, contracts, and compositions. Without 
a formal basis it is not possible to justify through formal verification the correctness conditions for 
service compositions and the satisfaction of contractual obligations in service provisions. We remedy 
this situation in this paper We present a formal definition of services with context-dependent con- 
tracts. We define a composition theory of services with context-dependent contracts taking into con- 
sideration functional, nonfunctional, legal and contextual information. Finally, we present a formal 
verification approach that transforms the formal specification of service composition into extended 
timed automata that can be verified using the model checking tool UPPAAL. 



1 Introduction 

In lfT2l and lITll . we introduced a formal framework, called FrSeC, that supports the specification, pub- 
lication, discovery, selection, composition and verification of services with context-dependent contracts. 
The work reported in this paper is founded on this framework. We provide a formal specification of 
services with context-dependent contracts and their compositions. The composition theory of services 
takes into consideration the functional, nonfunctional, legal, and contextual aspects of services. We also 
present a formal verification approach that transforms the formal specification of service composition 
into UPPAAL [2J timed automata in order to verify service properties using model checking. 

Service-oriented Architecture (SOA) is an emerging view of the future of distributed computing and 
enterprise application development [4J. However, current approaches for the specification, publication, 
discovery, selection, and provision of services fall short in important respects. First, the relationship 
between the service contract and the conditions in which the service can guarantee its contract has been 
ignored, however these are necessary in order to associate the context of the service provider and the 
context of the service requester. Second, contextual information [31 is not well represented and not 
rigorously applied in service discovery and service provision. Third, current composition approaches 
compose only service functionality and ignore nonfunctional requirements. Thus, service contracts, and 
context information that are part of services are left out of the composition, and verification. Fourth and 
the last, the published approaches do not use formal methods for the specification of services, contracts, 
contextual representation and application, and service composition. Without a formal basis it is not 
possible to justify through formal verification the correctness conditions for service compositions and the 
satisfaction of contractual obligations in service provisions. The work reported in this paper eliminates 
these shortcomings. 

The basic building unit for SOA-based applications is service. It is normally understood that ser- 
vice is an autonomous and platform-independent software program, having its own distinct functionality 
and a set of capabilities related to this functionality. These capabilities are usually invoked by exter- 
nal consumer programs and are usually expressed via a published service contract. A service contract 
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Figure 1: ConfiguredService 



establishes the terms of engagement with the service, provides technical constraints and requirements, 
and provides any semantic information the service owner wishes to make public H . We reckon that a 
Service Provider will package service functionality with non-functional attributes, service contract, and 
context. So, we decided to deal with ConfiguredServices, which are formalized in Section |2] A Service 
Provider may choose to compose ConfiguredServices. The composition mechanism itself may be driven 
by the business model of the Service Provider. Keeping this point of view, we discuss in Section [3] a 
formal composition theory of services {ConfiguredServices). Section [4] presents an approach to formally 
verify service properties in service compositions. In Section [5} we briefly, yet critically, compare our 
work with related work. Finally, Section [6] concludes the paper with a summary of ongoing work. 



2 ConfiguredService Definition 

Services are defined by service providers in a contract first approach. That is, the contract is defined 
before the implementation of service ||4|. The service provider determines all the possible contracts that 
this service should satisfy. Then, the service provider defines the ConfiguredServices that represents 
those contracts. After that, the service provider develops the ImplementedService that implements the 
different ConfiguredServices that provide the same functionality with different contracts and contexts. A 
ConfiguredService is to be published in Service Registry and made available for discovery and selection. 
A ConfiguredService is a package in which service functionality, service contract, and service provision 
context are bundled together. The Service Provider publishes the ConfiguredService elements. The pub- 
lished elements should be sufficient for the discovery and selection of this service. The essential elements 
that make this happen are contract and context, as shown in Figure [T] The contract will mcluAe. function, 
nonfiinctional properties and legal issues. Trustworthiness features are included in the nonfunctional 
part of the contract and legal issues include business rules and other trade laws within the context. 

• Function: A ConfiguredService provides a single function. The function definition will include 
the function signature, result, preconditions and postconditions. The signature part defines the 
function identifier, the invocation address, and the parameters of the function. Each parameter 
has an identifier and a type. The result part defines the returned data of the service function. 
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The preconditions define the conditions that should be true before the function invocation. The 
postconditions define the conditions that are guaranteed to be true after the function invocation. 

• Nonfunctional properties: A ConfiguredService definition includes nonfunctional properties that 
it can guarantee. These properties are to be chosen carefully so that they are verifiable, and en- 
compass both quality and quantity aspects of service. Trustworthiness and Price are examples. 
Trust itself is further divided into ConfiguredService trust and provider trust. These are explained 
in detail in the next section. ConfiguredService trust defines the trustworthiness properties that 
are related to service provision. It includes the features safety, security, availability, and reliabil- 
ity ||T5l . Safety defines the critical conditions that are guaranteed to be true by Service Providers, 
such as timing conditions. Security is a composite of data integrity and confidentiality. Availability 
can be defined as the extent of readiness for providing correct services. Availability is specified 
as the maximum accepted time of repair until the service returns back to operate correctly. Relia- 
biUty is the quality of continuing to provide correct services despite a failure. It is defined as the 
accepted mean time between failures. Provider trust defines the trustworthiness properties that are 
related to the Service Provider. It may include recommendations from other clients, and lowest 
prices guarantees. There is no agreed upon definition for Provider trust. The main issue here is the 
inclusion of verifiable information that makes a seller trusted. 

• Legal Issues: One of the essential elements of the ConfiguredService contract is the set of legal 
rules that constrain the contract. Business rules, such as refund conditions, interest and adminis- 
trative charges, and payment rules, form one part of legal issues. Another part is the set of trade 
laws enforced in the context of service request and delivery. Examples of the later kind are service 
requesters rights, privacy laws, and censor rules. In the literature lfl6l , no distinction was made 
between legal rules and nonfunctional requirements. We reckon that a clear distinction should 
be made between legal rules and nonfunctional properties. In many situations, if a nonfunctional 
property is 'a soft' requirement it may be ignored, however ignoring a legal rule is equivalent to 
'legal violation', which might land in legal disputes and even lead to loss of entire business. In 
essence, not enforcing a legal rule prevents the execution of a contract. 

The context part of the ConfiguredService will include the main parts ConfiguredService context and 
context rules. The ConfiguredService context defines the contextual information of the ConfiguredSer- 
vice. Context is formally defined in |[T9l using dimensions and tags along the dimensions. We illustrate 
context specification using the three dimensions WHERE, WHEN and WHO. The dimension WHERE is 
associated with a location, which may be one or more of {Point, Region, Address, Route, URI, IP}. The 
dimension WHEN is associated with temporal information, such as time and date. The dimension WHO 
is associated with subject identities, such as the names of Service Providers and Service Requesters. 
We can also use WHO dimension to associate information from job roles. The context rules define the 
contextual information related to the Service Requester that should be true for the Service Provider to 
guarantee the contract associated with the ConfiguredService. Rules are defined as constraints in a subset 
of Timed Computation Tree Logic (TCTL), the logic used in UPPAAL. In practice, constraints can be 
expressed as simple logical expressions within the first order predicate logic (FOPL), a subset of TCTL. 

Example 1 This example introduces a simplified case study STU, restricted to emergency road assistance 
service scenarios for automobiles. A typical scenario is the breakdown of a car on a highway, which 
requests for road-side assistance. The car sends information to the nearest road assistance center, which 
in turn will use the information received to identify the repair shop, tow truck and car rental companies 
in that zone. In this example we identify three ConfiguredServices, whose detailed definitions are shown 
in Figure^ 
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Figure 2: Roadside Emergency Services: ConfiguredServices Description 



2.1 Formal Notation 

We use a model-based approach to formally specify ConfiguredServices. The models are built from set 
theory and logic. The model is built incrementally, according to the template in Figure [T] 
Definition of Constraints: A constraint is a logical expression, defined over data parameters and at- 
tributes. Any well-formed formula built by using standard logical operators, quantifiers, and temporal 
operators allowed in TCTL [2] is a valid constraint. If C denotes the set of all such logical expressions, 
X G C is a constraint. The following notation is used in our definition: 

• T denotes the set of all data types, including abstract data types. 

• G T means Dt is a datatype. 

• V : Dt denotes that v is either constant or variable of type Dt. 

• Xy, is a constraint on v. If v is a constant then Xy, is true. 

• Vcj denotes the set of values of data type q. 

• X : : A denotes a logical expression x G C defined over the set of parameters A. 

Definition of Parameters: A parameter is a 3-tuple, defining a data type, a variable of that type, and 
a constraint on the values assumed by the variable. We denote the set of data parameters as A = {A = 
{Dt,v,X„)\Dt G T,v:Dt,X,. G C}. 

Definition of Attributes: An attribute has a name and type, and is used to define some semantic informa- 
tion associated with the name. As an example, each ConfiguredService can be given a version number, 
which is defined as an attribute. The set of attributes is a = {{Dt,Va)\Dt G T,Vq; : Df}. 
Definition of Context: A context is formalized as a 2-tuple j8 = {r,c), where r G C, built over the 
contextual information c. Context information is formalized using the notation in |fT9l : Let T : DIM 
— )■ 7, where DIM = {Xi, X2,...JCn} is a finite set of dimensions and I = {a\,a2, ■■■,a„} is a set of types. 
The function T associates a dimension to a type. Let T(X;) = a,-, a, G /. We write c as an aggregation of 
ordered pairs (Xj, vj), where Xj G DIM, and vj G '^(Xj). 

Definition of Contract: A contract is a 3-tuple a = (/, K", Z), where the service function /, the set of 
nonfunctional properties K and the set / of legal issues that bind the service contract are defined below. 

• Service Function: A service function is a 4-tuple / = {g,i,pr,po), where g is the function signa- 
ture, / is the function result, pr is the precondition, and po is the postcondition. A signature is a 
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3-tuple g = {n,d,u), where n = (x\x : string) is the function identification name, d = {x\x G A} is 
the set of function parameters and u = {x\x : string) is the function address, the physical address 
on a network that can be used to call a function. For example, it can be an IP address. The result is 
defined as / = {ni,q), where m = {x\x : string) is the result identification name and q = {x\x G A} 
is the set of parameters resulting from executing the ConfiguredService. The precondition pr and 
postcondition po are. data constraints. That is, pr = {y\y :: z,z ^ A} and po = {y\y :: z,z ^ A}. 

• Nonfunctional Property: A nonfunctional property of a ConfiguredService is a composite property, 
written as a 6-tuple K= {p,e,\lf,r\,p,tr), where p is the safety guarantee, e is the security guar- 
antee, f] is the availability guarantee, i/A is the reliability guarantee, p is the service cost and tr is a 
measure of the provider trust. The safety guarantee includes time guarantee p, and data guarantee 
Pj. We assume that time is a generic type. The time guarantee is defined as p, = {x\x : time), 
the time the service takes to provide its function. The data guarantee refers to the accuracy of 
data, and is defined as Pd = {x\x :: z,z C A}. Let H denote the set of security protocols that the 
Service Provider has followed to guarantee confidentiality and integrity constraints. Then the set 
£ = {x\x G H} defines the extent of security binding the service. The reliability guarantee refers to 
the guaranteed maximum time between failures, and is defined as i/a = {x\x : time). The availability 
guarantee refers to the guaranteed maximum time for repairs, and is defined as T] = {x\x : time). 
The price is defined as a 3-tuple p = {a,cu,un), where a = {x\x : N) is the price amount defined as a 
natural number, cu = {y\y: cType) is currency tied to a currency type cType, and un = {z\z '■ uType) 
is the unit for which pricing is valid. As an example, p = (100, $,/joMr) denotes the pricing of 
100$/hour. Provider Trust is defined as a 3-tuple tr = {ce,pg,re), where ce is recommendations 
from other clients, pg is lowest prices guarantees and re is recommendations from independent or- 
ganizations. Lowest price guarantee is represented by a flag pg = {a\a : Boolean). It is a Boolean 
that is true when a ConfiguredService can guarantee its price to be lower than the price of any 
other ConfiguredService providing the same functionality. Client recommendations and recom- 
mendations from independent organizations can be defined as sets of ordered pairs. In ce = 
{{a,b)\a : CLIENT, b G {Low, BelowAverage, Average, AboveAverage, High}}, a pair {a,b) rep- 
resents a client a whose recommendation is b. Likewise, in re = {{a,b)\a : ORGANIZATION, b G 
{Low,BelowAverage, Average, AboveAverage, High}}, a pair {a,b) represents an organization a 
whose recommendation is b. 

• Legal Issues: A legal issue is a rule, expressed as a logical expression in C. A rule may imply 
another, however no two rules can conflict. We write I = {y\y G C} to represent the set of legal 
rules. 

Putting these definitions together we arrive at a formal definition for ConfiguredService. 

Definition 1 A ConfiguredService is a 4-tuple s = (A, a,)8,a), where A is a set of parameters, a is a 
set of attributes, j8 is a context, and O is a contract. 

We remark that not all components of K may be relevant for a service, as shown in many later examples. 
In general, the trust domain, in which ce and pg are defined, must be a complete lattice |[201 . This 
property is essential in order to compare trust values of groups and compute minimum (maximum) among 
trust values. For the sake of simplicity, we assume in further discussion that trust values assumed by ce 
and re are whole numbers in the range 1 ... 5, where 1 denotes Low and 5 denotes High. This assumption 
will enable us to calculate simple averages, maximum, and minimum of a set of trust values. Example [2] 
illustrates the application of the above formal notation to the ConfiguredService defined in Example [T] 
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Example 2 Let rs denote the ConfiguredService for providing a Repair Shop who provides the services 
described in Figure^ The formal notation of ConfiguredService rs is Sy^ = {Ars,cCrs,Prs,<^rs,)> where 
the tuple components are explained below. 

• parameters: hrs = {{CarBroken,bool) , (deposit , double) , (CarType, string) , {failureType, string) , 
{HasAppointment,bool),{numberOf Hours, int)}. 

• attributes: = ^■ 

• context: 15,-s = {frs,Crs), where r^s = {{membership == caa)} is the context rule and Crs = 
{{Location, [Montreal , Canada))} is the contextual information of the emergency road service 
provider 

• contract: Ors = {f-s, T<^rs,lrs), where the elements of the 3-tuple are defined below: 

L contract functionality specification: frs = {gr.^,irs,Pf'rs,pOrs) 
LI function signature: g„ = {nrs,drs,Urs), where 

nrs = {ReserveRS) is the name, drs = {{CarBroken,bool), {deposit, double), 

{CarType,string), {failureType, string)} are input data parameters, andurs = {XXX) 

is the address 
L2 function result: irs = {inrs,(]rs) . where 

mrs = {Result RS) is the name and the set of output data parameters is 

q,-s = {{H as Ap pointment ,bool) , {number Of Hours, int)} 
L3 function precondition: prrs = {{CarBroken == true)} 
L4 function postcondition pors = {{HasAppointm ent == true)} 

2. contract nonfunctional property specification: Krs = {prs), Prs = {cirs,curs,unrs), where 
<^rs = (60) is the cost, cUrs = {dollar) is the currency, and unrs = {hour) is the pricing unit 

3. contract legal issue specification: Irs = {{deposit = 300), {CarType == toyota)}, where 
the deposit amount is 300 and the car type is toyota. 



3 Service Composition 

Altliougli service composition lias been considered before by some researchers Hllll no specific method 
has been put forth. In FrSec a service composition may be attempted either at design-time or at execution- 
time. The former, called static composition, is driven by Service Provider's business goals. The later, 
called dynamic service composition, is driven by user's demands at service provision contexts. In this 
paper, we focus only on static service composition. We present a few composition constructs, give their 
semantics and suggest a verifiable composition theory. 



3.1 Composition Constructs 

Defining a composite service includes defining the execution logic of the participant services. This 
section, inspired by [21], defines the composition constructs and informally motivates their execution 
logics. 

• Sequential composition construct Given two ConfiguredServices A and B, the expression 



A » B (Figure 3(a) I defines the sequential composition of A and B. The execution logic of this 
composite service is that ConfiguredService A is executed first, and its output may be used in the 
execution of ConfiguredService B, in addition to any input that B may require. In general, the 
expression Ai » A2 . . . » A^. denotes the execution of ConfiguredService A,+i with the result of 
execution of A, as an input, for / = 1 , . . . , ^ — 1, in addition to other input that A,+i might need. 
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Figure 3: a) Sequential, b) Parallel, c) Priority d) No order, e) Nondeterministic, f) Conditional, and g) 
Iteration Constructs 



Parallel composition construct ||: Given two ConfiguredServices A and B, the expression A\\B 



(Figure 3(b) i defines the parallel composition of A and B. The parallel composition A | |B models 
the simultaneous executions of ConfiguredServices A and B. In general, the evaluation of the ex- 
pression A i II A2 II ... \\Aic will create k service execution threads, one for each ConfiguredService. 
The result of this composite service is the merging of their individual results in time order. That 
is, the execution of the composite service finishes only when all service executions terminate. 



Priority construct ^: Given two ConfiguredServices A and B, the expression A -< B (Figure 3(c) 1 
defines that the service execution of A should be attempted first, and if it succeeds, the service 
B is to be discarded; otherwise, the execution of service B should be attempted. In general, the 
expression requires that the service executions be attempted deterministically in the order specified 
until the first successful execution of service. The meaning of the expression A 1 -<...-< A^- is that 
the service that can be successfully executed is the result of the composition. 

Composition with no order O: Given two ConfiguredServices A and B, the expression AOB 
(Figure 3(d)| ) defines that services A and B should be executed by the receiver, however the order 



of their executions is not important. The result of the composition is the set of results produced 
by the executions of the ConfiguredServices A and B. In general, the expression A 1OA2O . . . OA^ 
defines the composition of services A,-, / = \,k when all of them may be executed in no specific 
order. 

Nondeterministic choice construct I: Given two ConfiguredServices A andB, the expression A ? B 



(Figure 3(e) I defines the composition in which one of the services is executed nondeterministically. 
In general, Ai ? . . . ? A/t denotes the execution of a nondeterministically chosen service from the k 
operands. If the service A, is the nondeterministic choice, the result from the evaluation of the 
service A, is the result of evaluating the composition A\l . . . lA^. In using this composition it is 
understood that any service A, can be chosen for the intended purpose. 

Conditional choice construct (if-else) >: Given two service expressions Ei and E2, the composi- 
tion expression E\ >cE2 (Figure [3(f)|) states that if condition c evaluates to true then expression Ei 



is to be chosen for execution, otherwise expression E2 should be executed. 



• Iteration construct (while) o: The composition Eo^ (Figure 3(g) I states that the service expression 
E should be executed as long as c evaluates to true. 
Construct Binding All constructs have the same precedence, and hence a composite service expression 
is evaluated from left to right. To enforce a particular order of evaluations, parenthesis may be used. 
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Example 3 The execution logic of the composite service {At'c\ B) ^ (C| \D) ^ Fo^^, shown in Figure^ 
is obtained by putting together the execution logics from Figure^ 
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3.2 Semantics of ConfiguredService Compositions 

Every Service Provider has a business model. Motivated by the business rules and logic in the model, a 
Service Provider will determine the nature of composition for services. We want to emphasize that the 
meaning of a composition primarily rests on the chosen business goals and rules. Consequently, service 
compositions are very much unlike action compositions based purely on preconditions and postcondi- 
tions. As an example, a Service Provider may form B because service B can be provided only after 
service A has been provided. That is, service B cannot be realized without first executing service A. This 
is analogous to 'bootstrapping' before invoking any other system function in the domain of computing 
services. This implies that the precondition for invoking a system function includes the precondition for 
invoking 'bootstrapping', however it might require more conditions to be met. Moreover, the postcondi- 
tion of 'bootstrapping' and the postcondition of the system function invoked after that are both observed. 
In some domains, it might happen that the precondition for invoking service B is exactly the same as 
the postcondition of the first service A, and is not observable. Only the postcondition of B, after B is 
completed, may be observable. Given such subtle scenarios, it is hard to give one 'fixed' semantics for 
service compositions. Below we give the semantics for sequential composition. An account of the full 
semantics can be found in flOl. The proposed semantics is appropriate for one kind of business logic, and 
our approach can be used to provide semantics for different business logics. By providing an approach 
to formal semantics for composition constructs we are motivating how a theory of composition can be 
developed. 

Below we let A = (A^, a^, jSa, Oa), and B = (Ag, aB,pB, Ob) denote two ConfiguredServices, where 

j(3a = {rA,CA), = {rB,CB), Oa = {fA,KA,lA), Og = {fB,KB,lB),fA = {gA,iA, PrA, POa) , fs = {gB,iB,PrB, 

POb), gA = {nA,dA,UA), gB = {nB,dB,UB), Ia = {mA,qA), iB = {mB,qB), Ka = {pA,eA,YA,riA, PA,trA), 
and Kb = {Pb,£b, VB,'nB,PB,trB). For the sake of simphcity we assume that the currency type cType and 
the unit type uType are the same for all services. 

3.2.1 Sequential composition A » B 

The sequential composition of the ConfiguredServices A and B is the tuple (A/i>B,aA>B,j8A>B,OA>B), 
whose components are defined below. 



Parameters: Aa>b 
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- Input parameters: A,„p„,(A»B) = Ai„p„,(A) U (Ai„p„r(B) \ Ao„rp„r(A))> defined as the union of tiie 
input parameters of A, and input parameters of B that are not output parameters of A. 

- Output parameters: A,,„fp„,(A»5) = A,„,,p„,(A) UA„^,,p,,t{B), defined as the union of the output 
parameters of A and B. 

• Attributes: aA>s = U 

• Context: For ConfiguredServices A the context is jSa = {rA^CA)- This means that is true in 
context ca in order that A may be provided. Once the service A has been provided, the context and 
rules that are true in that context should be computed. Letting these rules and the context c^, we 
need to merge them with and cg, jS^ = {rB,CB) to arrive at ^a^b- With this rationale, we define 
j8a>b = {rA^B,CA^B), rA^B = r'A^rB, and ca>b = c'^Ucb, the smallest closure of contexts and 
Cfi. It is expected that C cg holds for most of the applications, because anything outside of cb 
can be ignored. The semantics of context union (U) and sub-context (C) and a detailed discussion 
of context calculus can be found in |[T9l . 

• Contract: Oa^b = {/a^b, ^a^bJa^b), where 

1. function: /a>b = {gA:>B,iA:>B, prA::^B, POa:>b) , gA:>B = {nA'>B,dA'>B,UA-:^B) Ja-^b = {mA»B, 
qA»B), where 



gA>5 : 






nA:>B 


= Ua^Ub 


naming convention 


dA:>B 


= dAUdB 


combine input data parameters 


ua-^b 


= {ua,ub} 


both function addresses are necessary 


lA-^B '■ 






mA^B 


= ma^ Mb 


naming convention 


(1a:>b 


= qA^qB 


combine output parameters 


prA^B 


= prAU{prB\poA) 


if B requires more constraints 


prA^B 


= prA 


if B does not require more constraints 


POA^B 


= pOA U pOB 


if poA is observable 


POA^B 


= POB 


if poA is not observable 



2. Nonfunctional Properties: jca»b = {pA^B,£A^B,WA^B,f]A^B,PA^B,trA^B) where, 

- Safety (timehness): Pa>b = Pa + Pb- 

- Safety (data): Pa»b = Pa U Pb- 

- Security: £a>b = £a U Eb- 

- Availability: T]a»b = r\A + r\B- 

- Rehability: ^a'>b = Min{^A:WB)- 

- Price: pa^b = {aA»B,cuA^B,unA^B) where cma>b = cua = cub, uua^b = uha = uub, 
and 

{qa + Qb normal pricing 
max{aA,aB^ promotional 
min{aA,aB^ special sale 

- Provider Trust: Let tVA^B = {ceA^B,pgA^B,reA^B) ■ Given a set St of trust values, it 
should be possible to define avg{st), choose{st), glb{st), and lub{st) which respectively 
computes the average, selects randomly one value, and computes the least and greatest 
values from the set Sf. Any one of these functions may be used by the Service Provider in 
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providing ce and re. Each choice has some significance. Choosing avg reflects 'unbiased 
views of customers', choosing choose reflects a randomly selected customer opinion, 
choosing gib reflects a conservative estimate, and choosing lub reflects the optimistic 
opinion of customers. For illustration, we use the function gib. We compute the trust 



sets as 












ceA\B = 


-- {{a, 


.b)\ 


{a. 


,b) £ ceA,ia,b) ^ ceg} 


recommendation 
given for A only 


ceB\A = 


-- {{a, 


.b)\ 


(a. 


,b) ^ ceA,ia,b) G ccb} 


recommendation 
given for B only 


ceAnB - 


-- {{a. 


• b)\ 




,bi) £ceA,{a,b2) G ceB,l 


7 = glb{b\ , ^2)} recommendation 
given for A and B 



Similar sets for re are defined. The trust for the composition A^ B can be defined for 
different semantics. 

* Business Logic: Service A is required for service B. In this situation the expectation 
is that those who bought service B should have obtained service A, and hence they 
bought the service A 3> B. That is, the recommendation for B dominates. With this 
semantics we define 

cca^b = ccAnB U ces\A 
rcA^B = re Am U reB\A 

* Business Logic: Those who bought service A are most likely to buy service B. In 
this situation buying A is a certainty. Not everyone who bought A may buy B. That 
is, service recommendation for A dominates. With this semantics we define 

CCA-^B = CCACiB U CeA\B 

rcA^B = rcAnB U re^\B 

* Business Logic: Both services are packaged together: With this semantics the Ser- 
vice Provider has to collect the sets ce and re from chents and organizations for the 
new service. 

In all above situations 

= pgA/\pgB 

3. Legal Issues: //i>b = /a U Ib, defined as the union of the issues of A and B. 

Example 4 The sequential composition rule is applied to compute rs ^ tt, where the ConfiguredSer- 
vices rs (repair shop) and tt (tow truck) are defined in Example^ The formal notation of composite 
ConfiguredService is Srs^tt = {^rs^tt,0Crs:^tt,Prs^tt,<yrs^tt), where the tuple components are 

• The CofiguredService parameters set is Krs^tt = {{CarBroken,bool), (deposit, double), (CarType, 
string) , (failureType, string) , (RequestTruck,bool), (HasAppointment ,bool) , (numberOf Hours, 
int), (RequestConfi,bool)}. 

• The ConfiguredService attribute set is (Xrs^tt = ^■ 

• The ConfiguredService context is prs^tt = {rrs^tt,Crs^tt), where the context rules are Vrs^tt = 
{(membership == caa)} and the context information iscrs^n = {{Location, (Montreal , Canada))}. 

• The ConfiguredService contract is Ors^tt = {frs^tt, ^rs^ttjrs^tt) 

• The contract function is frs^tt = {grs^tt,irs^tt,prrs^tt,pOrs^tt) 

• The function signature is grs^tt = {nrs^tt-:drs^tt-,Urs:^tt), where the name is nyg^tt = (ReserveRS&TT), 
the address is Urs^tt = (XXXYYY) and the input parameters aredrs^tt = {(CarBroken,bool) , (deposit, 
double), (CarType, string), (failureType, string), (RequestTruck,bool)}. 
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• The function result is irs^tt = {'nrs^tt,^rs^tt) > where the resuh name is nirs^tt = {ResultRS&TT) 
and the output parameters are qrs^tt = {{Has Appointment , bool),(numberOf Hours, int), (Request 
Confi,bool)}. 

• The precondition is pr^s^^tt = {{CarBroken == true), (RequestTruck == true)} and the postcon- 
dition is pOrs^tt = {{HasAppointment == true), {RequestConfi == true)}. 

• The contract legal issues are Irs^tt = {{deposit = 300), {CarType == toyota)}. 

• The contract nonfunctional properties are Krs^tt = {Prs^tt), where the price is Prs^tt = {drs^tt, 
curs^tt,'^nrs^tt), the price amount is a,-s^tt = {{60 * numberOf Hours) + 100), the price currency 
is curs^tt = {dollar) and the price unit is unrs^tt = {oneTime). 

4 Formal Verification 

A service composition consists of multiple interacting ConfiguredServices that provide a functionality 
to meet a specific set of requirements. It is essential to verify that the functional behavior of the ser- 
vice composition meets the requirements of the service requesters while taking into consideration the 
nonfunctional, legal and contextual conditions. Instead of defining a new verification tool to verify the 
service composition we follow a transformation approach. In this approach, a formally defined service 
composition can be automatically transformed into a model understood by an available verification tool 
that can then be used to perform the formal verification. The goal in our research is to use different 
verification tools in order to verify a wide range of properties and target different kinds of systems. This 
is because different verification tools differ in their requirements and abilities. In this paper, we define 
the transformation rules to generate a model that can be verified using UPPAAL [2] model checking tool. 

A full account of UPPAAL language and tool can be found in ||2l. In essence, UPPAAL extends 
the definition of timed automata (TA) with additional features. The features that are relevant to this 
paper are (1) Templates that represent TAs with optional parameters and local variables; (2) Global 
variables and user defined functions, that are introduced in a global declaration section, and shared by 
all templates; (3) Binary synchronization that forces two TAs to have a synchronized transition caused 
by an event; (4) Channel that models an input event (labeled with ?) or an output event (labeled with !) 
in a synchronous transition; (5) Committed Location that models a state where time is not allowed to 
pass, and allowed to have an outgoing edge; (6) Expressions that include Guard expressions involving 
variables and clock variables to restrict transitions, Assignment expressions, which are used to set values 
of clocks and variables, and Invariant expressions, which are defined at locations to specify conditions 
that should be always true; and (7) Edges denoting transitions between locations. An edge specification 
consists of the four expressions 1) Select, which assigns a value from a given range to a defined variable, 
2) Guard, an edge is enabled for a location if and only if the guard is evaluated to true, 3) Synchronization, 
which specifies the synchronization channel and its direction for an edge, and 4) Update, an assignment 
statement that resets variables and clocks to required values. UPPAAL can check safety, reachability, 
and liveness properties that are expressed in TCTL |^. 

4.1 Transforming the Service Composition into UPPAAL TA 

This section presents the rules for transforming a service composition into a UPPAAL TA. Let S = 
{si,...,s„} be the set of ConfiguredServices to be composed. Let T be the execution flow defining the 
composition, and SC = {S,T,A, a,^,o) be the resulting composition. Let TA = {L,Lq,K,A,E,I) be the 
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definition of a UPPAAL TA, where L is a set of locations denoting the states, Lq is the initial state, K is 
a set of clocks, A is a set of actions that cause transitions between locations, £ is a set of edges, and / is a 
set of invariants. The transformation rules will construct T = {tai ,...,tan}, a set of UPPAAL templates. 
The first step is to define the following in the global declaration section in UPPAAL. 

1. Two channel variables are defined for each j,. The first represents the request and the second 
represents the response. 

2. A Boolean variable is defined for every precondition and input parameter in SC and assigned 
to true. These variables are used to verify if preconditions and input parameters exist before 
execution. 

3. A Boolean variable is defined for every postcondition and output parameter in SC and assigned 
to false. These variables are used to verify if postconditions and output parameters exist after 
execution. 

4. A typed variable is defined for every parameter in SC. The type can be any simple type, such as 
int, or a structured data type. 

5. The following variables of type double are defined and assigned to for each composition flow: 

• PathPrice, which represents the total price of the composition flow. 

• PathAvailability, which represents the availabihty of the composition flow. 

• PathReliability, which represents the reliabihty of the composition flow. 

• PathTime, which represents the safety time guarantee of the composition flow. 

6. Boolean variables representing the elements of the legal issues are defined. These variables are 
used in defining the Legal issues as Boolean statements. 

7. A UPPAAL structure that represents the contextual information of the service requester is defined. 
The structure contains dimensions and associated tag values. 

4.1.1 Transformation Rules 

The transformation rules are divided into two sets. The first set defines the rules to transform an indi- 
vidual ConfiguredService into a TA. The second set defines the rules to transform the composition flow 
into a TA. Each ConfiguredService can be mapped to a UPPAAL template in a one to one manner. A 

ConfiguredService Si = {Ai,ai, j^i.Gi) is mapped to a template tat = {Li,Loi,Ki,Ai,Ei,Ii). Following are 
the transformation rules to generate for each si. 

1. For each tai create two locations L,- = {/i , /2}, and set the first location as the initial state Lq; = {li}. 

2. Create two edges in £",■ = {ei,e2} in /a,, with edge ei directed from h to h and edge e2 directed 
from /2 to /i- 

3. Define an action for each 5, and add it to A,. 

4. Add to edge ei the following expressions: 

(a) Add to guard the condition that all Sj preconditions are equal to true. 

(b) Add to guard the condition that all Sj input parameters are available. 

(c) Add to guard the condition that the Sj contextual rules are satisfied. 

(d) Add to guard the condition that the Si legal rules are satisfied. 

(e) Add to Sync the channel variable corresponding to j,- request and follow it with ?. 
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5. Add to edge €2 the following expressions: 

(a) Add to update the statement that assign all Si postconditions variables to true. 

(b) Add to update the statement that assign all Sj output parameters variable to true. 

(c) Add to Sync the channel variable corresponding to si responses and follow it with ! . 

The steps described above generates a TA for each ConfiguredService. The next step is to generate the 
main TA that maps to the composition execution flow. Before generating this TA, the composition flow 
should be flattened to contain only sequential composition construct In essence, every composition 
flow can be flattened into a set of sequential composition flows of ConfiguredServices lITOl . 

Example 5 The composition (A \>c\ ^ (C| \D) ^ Fo^2 defined in Example |5] can be flattened into 8 
composition flows, where Xc indicates that X is associated with condition c. These are: (1) Ad ^ C^D, 
(2) Aci > C>D > Fc2... > Fc2, (3) A,i > D>C, (4) A^ > D>C > F,2... > ivz, (5) B^ci > C>D, 
(6) B^,i > C»D » Fc2... > F,.2, (7) B^d > £>»C and (8) B^^i > D%C > F,2..- > F,2. 

The main TA will contain an idle state. For each flattened composition flow, a path of states is created in 
the main TA starting from this idle state according to the following rules. 

1. For each ConflguredService create two states. The first represents the request for the Configured- 
Service and the second represents the completion of the execution. 

2. For each ConfiguredService, if it contains a safety time constraint, create a new clock and add the 
timing constraint as an invariant on the location. Exception: if the sequential construct resulted 
from parallel flattening X^Y, only add the invariant to the state with the highest time constraint 
of X and Y, and make the other state a committed state. 

3. For each ConfiguredService create two edges. The first connects the state representing the previous 
ConfiguredService in the flow, except for the first ConfiguredService where it connect idle state, to 
the first state defined in rule 1 . The second connects the first state to the second state of rule 1 . 

4. If the ConfiguredService is associated with a condition (conditional choice or iteration condition), 
add this condition as a guard statement on the first edge of rule 3. 

5. If the ConfiguredService has a safety data conditions, add this condition as a guard statement on 
the first edge of rule 3. 

6. If the ConfiguredService has a price, add to the second edge of rule 3 an update statement that adds 
the price to the path price variable. 

7. If the ConfiguredService has an availability nonfunctional property, add to the second edge of rule 
3 an update statement that adds the availability to the path availability variable. 

8. If the ConfiguredService has a reliability nonfunctional property, add to the second edge of rule 
3 an update statement that adds the reliability to the path reliability variable. Exception: if the 
sequential construct resulted from parallel flattening, the update statement is only added to the 
edge with the highest reliability time. 

A reasoned justification for the transformation steps is given in ifTOl . 
4.2 Verification 



Using UPPAAL editor, the ConfiguredServices and their composition are specified as UPPAAL templates 
following the automatic transformation rules defined in Section 4. 1 UPPAAL verifier can be used to 
verify the following properties. 
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• Context: The context rules are not contradictory, and are met for each ConfiguredService. 

• Functionality: The behavior of the composition is correct with respect to functionality, which 
includes verifying. 

- The preconditions of each participating ConfiguredService are met before invocation. 

- The input parameters of each participating ConfiguredService are available before invocation. 

- The composition generates the required postconditions and output parameters. 

• Nonfunctional and trustworthiness properties: The behavior of the composition is correct with 
respect to nonfunctional properties, which includes verifying. 

- The composition price is greater than or equal the price of any possible execution flow. 

- The composition safety time constraint is greater than or equal the time constraint of any 
possible execution flow. 

- The composition availability time is greater than or equal to the availability time of any 
possible execution flow. 

- The composition reliability time is greater than or equal to the reliability time of any possible 
execution flow. 

• Legal issues: The legal rules are not contradictory, and are met for each ConfiguredService. 

Example 6 Applying the transformation rules defined above to the service composition Re pair Shop ^ 
TowTruck ^ CarRental introduced in Example^ the composition is transformed into 4 TA's mapped 
to 4 UPPAAL templates, a template for each ConfiguredService and a template for the composition 
flow. The TA mapped to the ConfiguredService RepairShop is tars = {Lrs,LQ,-s,K,.s,Ars,Ers,Irs), ci^ ^^^n 
in Figure 5(a) where the tuple components are explained below 

• The set of locations is Lyg = {idle,RepairShopProcessing} and the initial location is Lq^s = idle. 

• The set of clocks is kys = <I> and the set of invariants is Irs = ^■ 

• The set of actions is Ars = {Schedule Apt ,AptCon firmed}. 

• The set of edges is Ers = {{idle — RepairShopProcessing) ,{RepairShopProcessing — idle)}. 

• The edge connecting 'idle' to 'RepairShopProcessing' has the following statements, where 'pa- 
rameters' indicates the variable indicating the availability of the parameter 'parameter': 

- Guard.' (RequesterContext . membership==l ) && (CarBroken==true) && (car 
Type==toyota) &&carTypeB&&f ailureTypeB. 

- Synchronous.- ScheduleApt?. 

The edge connecting RepairShopProcessing to idle has the following statements: 

- Update.' HasAppoitment=true, NumOf DaysB=true, Deposit=Deposit +300. 

- Synchronous.- AptConfirmed!. 

The TAs mapped to the ConfiguredServices TowTruck and CarRental are created in the same manner. 
Figure [6| shows the generated main TA. UPPAAL is used to verify several properties listed below. The 
notations M . i and M . Final_l are used to denote the initial and final states of the TA M. 

• The composition does not contain any contradiction and can be executed. If the UPPAAL statement 
E<> M . Fi nal_l is verified it implies that it is possible to reach the final state of the composition 
fiow. Reaching the final state indicates that all conditions are met and no contradictions exist. 
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RepaEtShopProcessing _^ _^ , „ CarRentalProcessing 

— ^ TawTruckPracessing ^ 

SchedulaApL? / \ AptCanfirmedi 






(a) (b) (c) 

Figure 5: a) RepairShop TA, b) TowTruck TA, and c) CarRental TA 



DC 1 TT 1 

- - PathPrioe=PathPrice+100 

SchedulaApt! AptConfirmed? RequestTrLicI^! RequesLConfirmed^^ 



Path Prioe=Path Price +300 



Final_1 Qfe 

o 



RentCar! 
1 



CarRented? 
Path Price=Patli Price + 1 80 

Figure 6: Example [6] Main TA 

The context rules are met. For each context rule an UPPAAL verification condition is generated 
and verified. For example, A [ ] M.i imply RequesterContext . age>=2 1 co«fif/- 
tion to be verified to assert that the requester is older than 21. Here, RequesterContext is 
the UPPAAL structure holding the contextual information of the service requester 

The composition input parameters are defined before executing the composition fiow. For example, 
A[] M.i imply iai.lurely^B'Q is the condition to be verified in order to assert that the car 
f ailureType parameter is available before execution. Here, f ailureTypeB is a Boolean 
variable representing the availability of the parameter failure! ype. 

The composition output parameters are defined after executing the composition fiow. For exam- 
ple, A [ ] M.i imply ! NumOf Day sB is the condition to be verified in order to assert that the 
number of days needed to fix the car are not known before executing the composition. The state- 
ment A [ ] M.i imply ! NumOf DaysB, if verified, asserts that the number of days is known 
after executing the composition. The parameter NumOf Day sB is a Boolean variable representing 
the availability of the parameter NumOf Days. 

The preconditions are met before executing the composition and the postconditions are met after. 
For example, A [ ] M.i imply NeedCar==true will have to be verified to assert that the 
precondition "NeedCar" is true at the initial state. 

The composition of nonfunctional properties are correct. For example, A [ ] M . Final_l imply 
f irstPathPrice <= 600 will have to be verified to assert that the price of the composite 
service is less than 600, where 600 is specified as the price of the service composition. 

The composition result of the legal rules are correct. For example, A[] M.Final_l imply 
4 0>=Deposit will have to be verified to assert that the deposit is less than 400, if the legal rule 
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states that "The service requester should deposit 400 before requesting the service composition ". 

5 Related Work 

Many researchers, such as 0, ||5l, ||9]|, 161 and ifTTl . have investigated the formal models automata, 
Petri-net and process algebra as service models and used a transformation approach to arrive at the for- 
mal models from service descriptions in one of the languages BPEL [14], WS-CDL ll22l or Ore |[T3]| . 
However, these formal languages can model only the functional behavior of services. Hence, the trans- 
formation approaches practiced so far are restricted to only the functionality in composite services, while 
the nonfunctional, legal and contextual constraints are ignored. As a consequence, the known verifica- 
tion processes cannot be applied to construct composite services in our model. The merit of our work is 
twofold. One is the introduction of a variety of compositions which can be tailored to the semantics of 
a business logic, and the other is the ability to combine functional and nonfunctional behavior together 
with legal and contextual constraints in model checking. 

6 Conclusion 

Our research aims to define a formal framework for managing and providing service with context- 
depended contracts. As part of this framework, in this paper we have presented an approach for the 
formal specification and verification of services with context-dependent contract. We presented a for- 
mal definition and a formal composition theory of ConfiguredServices. Finally, we presented a formal 
transformation approach to transform service composition into extended timed automata that can be ver- 
ified using UPPAAL tool. Currently, we are working on defining a dynamic composition approach that 
automates the service composition process at execution-time. We are also investigating dynamic recon- 
figuration issues arising out of defaults and dynamic compositions of services. Finally, we are currently 
developing a set of tools that automate the composition and verification process. 
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